【レポート】 EC2仮想基盤の進化 (C5 Instances and the Evolution of Amazon EC2 Virtualization) #reinvent #CMP332
はじめに
本記事は AWS re:Invent 2017 のセッション「CMP332 - C5 Instances and the Evolution of Amazon EC2 Virtualization」のレポートです。
※写真が多めになっています
スピーカー
- Anthony Liguori - Senior Principal Engineer
概要
Over the last 11 years, the Amazon EC2 virtualization platform has quietly evolved to take advantage of unique hardware and silicon, an accelerated network and storage architecture, and with the launch of C5 instances, a bespoke hypervisor to deliver the maximum amount of resources and performance to instances. Come to this deep dive to get a behind-the-scenes look at how our virtualization stack has evolved, including a peak at how our latest generation platform works under the covers.
レポート
- 開場前、隣に座った海外のかたが「新しいハイパーバイザーに期待している」と興奮気味に話していたのが印象的でした
Nitroとは？
- 「Nitro Hypervisor」とは AWS の新世代のハイパーバイザですが、「ハイパーバイザ」以上でも以下でもありません
- https://aws.amazon.com/jp/ec2/faqs/ より
Q: Amazon EC2 の新しいハイパーバイザーとは何ですか?
Amazon EC2 の新しいハイパーバイザーは、C5 インスタンスの導入とともに採用され、主に C5 インスタンスの CPU とメモリの分離を実現するコンポーネントです。VPC ネットワーキングと EBS ストレージのリソースは、すべての最新世代の EC2 インスタンスファミリの一部である専用ハードウェアコンポーネントによって実装されます。Linux カーネルベースの仮想マシン (KVM) のコアテクノロジーをベースに構築されていますが、汎用オペレーティングシステムコンポーネントは含まれていません。
仮想化技術
- ハイパーバイザとはいえ、ブラウザやオフィスアプリと同じ「ソフトウェア」である
- 機械語を使って解説（会場笑い）
- OS向けのシステムコールが発生したときに、VMM がtrapしエミュレートする
- その分パフォーマンスが落ちる
- VMM : Virtual Machine Monitor
- ハイパーバイザの「心臓（heart）」
- 10〜数百のデバイスモデル（ソフトウェア実装デバイス）
- 1974年から基本的なところは変わっていない
- "Not all of the assumption held true through..."
- 「前提のすべてが真であるとは限らない」（by Google翻訳）
1972 〜 2006
- 初期の Intel プロセッサは trap しない
- ケンブリッジ大の Xen プロジェクトが上手い方法を見つけた
- 「準仮想化（Paravirtualization）」は OS に trap を追加する
- ハイパーコール（OS へのシステムコール）はダイレクトに VMM へ
- EC2 は Xen 準仮想化技術を使ってローンチされた
Nitro システムの進化 - およそ2012
- ソフトウェアのみのアーキテクチャより良くは出来ないか？
- デバイスモデルはCPUやシステムリソースと競合しジッタが発生する
- 最先端の (state-of-the-art) インスタンスタイプを求める旅路は 2012 から始まった
CR1 (Nitroなし) - 2013/01
- Xen ハイパーバイザ
- インスタンスストア、EBS、ネットワーク全てにデバイスモデル(DM)
C3 (初期のNitro) - 2013/11
- Xen ハイパーバイザ
- ENI 対応
- ネットワークはENIへ
- インスタンスストアとEBSにDM
C4 - 2015/01
- Xen ハイパーバイザ
- ENI
- EBS ボリュームのみに DM
X1 - 2016/05
- https://aws.amazon.com/jp/ec2/instance-types/x1/
- Xen ハイパーバイザ
- ENI
- インスタンスストレージ用にDM追加
- 大規模メモリのため（？）
I3 - 2017/02
- https://aws.amazon.com/jp/about-aws/whats-new/2017/02/now-available-amazon-ec2-i3-instances-next-generation-storage-optimized-high-i-o-instances/
- ストレージ最適化ハイ I/O インスタンス
- Xen ハイパーバイザ
- ENI
- インスタンスストレージはハイパーバイザ経由でNVM上に
残ったのは。。。
- レガシーとして残ったところ
- Xen ハイパーバイザ
- EBS 向けのデバイスモデル
C5 - 2017/11
- ハイパーバイザを Nitro に
- ENI
- EBS はハイパーバイザ経由で
EC2 ベアメタル - 2017/11
- ハイパーバイザなし
- ENI
- インスタンスストレージとEBS
VMware on AWS - 2017/08
- EC2 ベアメタルの上にVMware
The Nitro System
- Nitro Hypervisor
- 軽量ハイパーバイザ
- Nitro Card
- ストレージ
- ネットワーキング
- 管理（マネジメント）
- モニタリング
- セキュリティ
- Nitro Security Chip
- マザーボードに統合
FAQ
- 既存の AMI は Nitroベースのシステムで動くか？
- ENI 対応済みの AMI であれば必要なドライバがそろっている
- アプリケーションに手を加える必要はあるか？
- ほとんどの場合必要ない。自分自身が EC2 上で動いているかどうかによって振る舞いを変える明文化されていない仕様があると、手を加える必要があるかもしれない
- 今後全ての新しいインスタンスタイプはNitroシステムベースになるのか？
- ゆくゆくは、（全てではないが）ほとんどの新インスタンプタイプはそうなる。既存のインスタンスタイプをNitroにコンバートするプランはない。既存（Xenベース）のインスタンスは適切に使い続けられる。
この次は？
（※このあとのスライドは用意していない = 何も決まっていない、とのことだそうですｗ）
質疑応答から
- 細かいパフォーマンスチューニングは当然続けられていく
- EBS と通常の通信（ネットワーク）は HV で分離されている、互いに影響することはない
最後に
EC2 は長らく安定した基盤で動いている。。。とおもっていた時期もあったんですが、全くそんなことは無かったです。新サービスの公開に合わせて細かく進化しつつ、最終的に Xen から抜け出すところまで来たという感じでしょうか。
また、以前に発表のあった VMware on AWS の基幹技術がそのまま EC2 bare metal につながっていることが分かり、そういった舞台裏が除けたのも興味深かったです。
手前味噌ですがわたしも過去（前職で）、Xen のシステムを KVM ベースに移行する案件を主導した経験があり、その時のことを思い出して胸が熱くなったりもしました。今後も EC2 は見えないところで進化していくと思います。
